home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 1
/
Cream of the Crop 1.iso
/
UTILITY
/
FSULTRA1.ARJ
/
README
< prev
next >
Wrap
Text File
|
1992-06-18
|
7KB
|
208 lines
FSU - ULTRA The greatest random number generator that ever was
or ever will be. Way beyond Super-Duper.
(Just kidding, but we think its a good one.)
Authors: Arif Zaman (arif@stat.fsu.edu) and
George Marsaglia (geo@stat.fsu.edu).
Date: 27 May 1992
Version: 1.05
Copyright: To obtain permission to incorporate this program into
any commercial product, please contact the authors at
the e-mail address given above or at
Department of Statistics and
Supercomputer Computations Research Institute
Florida State University
Tallahassee, FL 32306.
See Also: README for a brief description
ULTRA.DOC for a detailed description
-----------------------------------------------------------------------
SUMMARY OF CONTENTS
Every file in this distribution is described in this file.
THE MAIN CODE
-------------
The assembly code (using TASM 2.0) for the random number generator
is contained in the files:
ULTRACOD.INC
ULTRADAT.INC
An interface file, which includes these files and defines a particular
language interface, must be written for each language. The files
ULTRA_C.ASM - Turbo C++ 1.0
ULTRA_TP.ASM - Turbo Pascal 6.0
ULTRA_LH.ASM - Lahey Fortran
ULTRA_FR.ASM - IBM Fortran/2
define the interfaces for the abovementioned languages. It is easy to
write other interfaces, given a description of the calling sequence
for the language.
THE C IMPLEMENTATION
--------------------
ULTRA.C
ULTRA.H
is a C implementation of the same algorithm, which is about half
as fast as the assembler version. Those who wish to port it to
other architectures may wish to use it as a starting point.
We would like to hear of any successful ports.
ULTRAMAC.C
is the same as ULTRA.C, but uses macros rather than function calls
to implement many of the random number procedures. This makes it a
bit faster. On the other hand occaisionally, macros behave slightly
differently from functions, so use it carefully.
THE "FAST" VERSION
------------------
If the variable "fast" is defined (via the -dfast switch for TASM, or
-Dfast for Turbo C), the above programs will skip one step (the mixing
with a congruential generator) in the algorithm to produce a faster
version of the same routines, which produces an inferior quality of
random numbers. This is not recommended for mathematical work.
THE "X" version
---------------
For those fortunate ones with 80386 or 80486 machines, some speed gains
are possible by using the 32bit capabilities of these CPU's. A whole
set of new programs:
ULTRXCOD.INC
ULTRX_C.ASM
ULTRX_TP.ASM
ULTRX_LH.ASM
ULTRX_FR.ASM
implement this version.
OBJECT FILES
------------
For those without access to TASM, compiled version of the routines are
provided in a subdirectory. The names of the .OBJ files are coded
using the following scheme:
All .OBJ file names begin with "ULT_", followed by a two letter code
for the language:
CT, CS, CM, CC, CL CH : for Turbo C (tiny, small, medium, compact,
large and huge) memory models.
TP - Turbo Pascal
LH - Lahey Fortran
FR - IBM Fortran/2
An additional suffix of F denotes the fast version
An additional suffix of X denotes the 80386/80486 version
Thus ULT_CMFX.OBJ is the Turbo C medium model Fast 80386/80486 version.
For convenience for Turbo Pascal users the TPU files (version 6.0)
ULTRA.TPU ULTRAF.TPU
ULTRAX.TPU ULTRAFX.TPU
have been included. To make some TPU's for a different version of Turbo
Pascal, use the file
ULTRATPU.PAS
DEMO/TEST
---------
A program to demonstrate the use as well as to serve for a benchmark
test was written in all the languages which have been implemented.
The programs are:
DEMO.C
DEMO.TP
DEMO.FOR
All the languages gave identical output (except Turbo C, tiny model
which seems to use some different rounding for printouts and hence
differs in the floating point numbers. Using Turbo Debugger it was
verified that the numbers being generated are identical, but the
printf routine prints them differently!).
IBM Fortran/2 seems to crash and/or behave unpredictably with the
"X" versions of ULTRA. For this reason, they were excluded from the
compiled programs. I don't know why this happens. The assembler files
are included for those who wish to explore this.
TIMINGS
-------
A file called
TIMINGS.C
is included for those who wish to see how fast is fast. This is
written using the Zen Timer library (ZTIMER11.ZIP) which provides
microsecond timing accuracy on the PC's. The library is not included
but is available for remote ftp from SIMTEL or any of its mirrors,
e.g. (wuarchive.wustl.edu in /mirrors/msdos/c/ztimer11.zip)
MAKEFILE
--------
Using the make utility, it is easy to excercise the various parts
of this package. The `make' program is usually supplied with all
Borland products, but public domain versions exist and can be found
on SIMTEL as well. Here is a list of what make can do:
Command Effect
------- ------
make will remake all the .obj files
make c will make all the Turbo C .obj files
make tp will make all the Turbo Pascal .tpu files. You
need to do this if you don't have TP 6.0.
make lahey will make all the Lahey Fortran .obj files
make fort will make all the IBM Fortran/2 .obj files
make demo will run all the demos
make democ will run all the Turbo C demos
make demotp or `make demolahey' or `make demofort'
will run demos for the other languages.
The demos will result in a file called dif.out,
which will compare the different versions to see
if they produce the same output.
make clean will remove all the junk created.
You may need to edit the file called
MAKEFILE
to reflect the paths of the various compilers on your machine
BUGS:
-----
There seem to be problems using 32bit code with IBM Fortran/2 and
with the Turbo-C Tiny model.
The Tubro-C bugs persist even with "TCC -MT DEMO.C ULTRA.C" where
there is no assembler code. When I run it in the integrated enviroment,
or in Turbo Debugger, it runs flawlessly. I am baffled.
CHANGES: (from ULTRA101.ZIP)
--------
Further speedup of assembler code.
More than doubled the speed of ULTRA.C (using if's to do SWB).
Caught serious error in vni's. Modified program so it could
be implemented on machines which worry about alignment.
This caused added space, and changed the output stream.